home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 2021 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  6.0 KB
  1. Path: sn.no!not-for-mail
  2. From: mobergru@oslonett.no (Rune Moberg)
  3. Newsgroups: comp.lang.c++,comp.lang.pascal.delphi.misc
  4. Subject: Re: C++ with Zapp vs. Delphi
  5. Date: 15 Jan 1996 15:41:24 +0100
  6. Organization: CD-Player Pro author!
  7. Message-ID: <Eul+w0JfFyQD089yn@oslonett.no>
  8. References: <4coar6$d4n@sun4.bham.ac.uk> <4coip7$69s@news1.usa.pipeline.com>
  9.  <fRA+w0JfFG5X089yn@oslonett.no> <4dcc4d$6anc@tigger.cc.uic.edu>
  10. NNTP-Posting-Host: hasle.sn.no
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset=ISO-8859-1
  13. Content-Transfer-Encoding: 8bit
  14.  
  15. In article <4dcc4d$6anc@tigger.cc.uic.edu>,
  16. olczyk@sunphy1 (Thadeus Olczyk) wrote:
  17. >As long as Delphi supports the toxic combination static typing and 
  18. >single inheritance , people will not be able to use polymorphism
  19. >to replace case statements which will always make Delphi slower in any
  20. >large application. 
  21.  
  22. Ok. Further down you question my ability to read. Well, I know I can
  23. read, but I'm not sure we've read the same stuff... Thus we still argue.
  24.  
  25. Anyway, in Bjarne's book about C++, which I haven't actually read, I just
  26. looked up "polymorphism", and Bjarne says (this can take a while, I
  27. type slow, since my keyboard has a sticky n-key):
  28. "Pointers to functions can be used to provide polymorphic routines, that
  29. is routines that can be applied to objects of many different types:
  30.  
  31.   typedef int (*CFT) (void*,void*);
  32.  
  33.   void sort(void* base, unsigned n, unsigned int sz, CFT cmp)"
  34.  
  35. (don't worry, the n-key wasn't sticky after all, so typing went ahead
  36. at full speed. Bjarne mentions MI a couple of places (4), but not as
  37. a requirement for polymorphism)
  38.  
  39. Now, I have some C experience (half a year), but the above is totally
  40. unreadable to me (the function header). Anyway, the concept is familiar;
  41. you have a function (or preferably a method) who accept an object as a
  42. parameter.
  43.  
  44. The method can access that object's public properties, methods, whatever,
  45. provided the object descends from a known base object that the function
  46. knows about (i.e. the function assumes that the object reference passed
  47. has a method named e.g. "mymethod" which is inherited by all it's children)
  48.  
  49. So far, this is very possible in Object Pascal, and a concept heavily
  50. used by Delphi. When you put a component on a form, you can attach event
  51. handlers. The parameter of an event handler is "Sender" of type TObject,
  52. thus I can share the same event handler among different components,
  53. and use typecasting whenever I need to reference something specific to
  54. a child object.
  55. thus:
  56.   (Sender as TEdit).CutToClipboard;
  57. will work for TEdit and all descendants of TEdit, but will generate an
  58. exception for any other object.
  59.  
  60. Object Pascal has a different type cast (also available in Delphi) that
  61. instead of generating an exception will most probably crash (AFAIK):
  62.   TEdit(Sender).CutToClipboard;  {a somewhat more direct approach}
  63.  
  64. (Yes, the Object Pascal standard lacks certain new features specific
  65. to Delphi, but this might change due to Delphi's popularity. I believe
  66. we'll probably see Delphi for other platforms within two years. I'm not
  67. depending on this, all I want is a NT version)
  68.  
  69. >Let's. RAD has recently come into disfavor in publications like JOOP, Object,
  70. >and even Byte. Last summer InfoWorld reported a growing disillusionment
  71.  
  72. Borland has a couple of big customers that have shared their success
  73. stories with the public. Remember, Delphi isn't even a year old, so the
  74. publications you've mentioned aren't really uptodate. I even emailed a guy
  75. who wrote a piece for Byte last year (about RAD, summer issue), and he
  76. thought Delphi was ok. RAD so far has meant VB. Delphi is not VB. Granted,
  77. it's simple to use, but it's powerful at the same time.
  78.  
  79. >I would like to see how you justify a claim of ease of mainenance when Delphi 
  80. >does not support MI. Implication-- under some circumstances one cannot abstract
  81. >out common behavior and therefor must cut and paste code-- ie-- they must copy bugs. Everyone I know agrees that that causes a maintenace nightmare.
  82.  
  83. Your claim. No copying of code is done here.
  84.  
  85. The component library makes it easy to maintain a library of components,
  86. thus enhancing reuse and OOP.
  87.  
  88. >readable. I should also say that I have never met a C/C++ programmer who had
  89. >trouble reading well-written C/C++. Poorly written C/C++ is another matter, 
  90.  
  91. Well, I had Turbo C at school (half a year), and got a nice grade (1.5
  92. on a scale from 1 to 6, 1 top) after exams were done, but I find it very
  93. difficult to read C code and C++ is thus impossible. Pascal is much
  94. more readable and easier to learn.
  95.  
  96. >I've never seen much difference, except to say that in the case of RAD tools
  97. >you get a lot of people who only think they are programmers writing a lot of 
  98. >crappy code.
  99.  
  100. I have no statistics on this, but I won't argue with you, just want to
  101. mention that there are a lot of competent Delphi people around, just
  102. check out the various Delphi www sites and look at the freeware components
  103. out there. Serious work has been done and is done in Delphi, and it's
  104. usually done pretty fast (compared to traditional tools). We Delphians
  105. might not get the upper hand in these discussions, but atleast we get
  106. our apps out the door faster! :-)
  107.  
  108. >: Seems strange, coming from someone who just wanted to compare VC"++" with
  109. >: Delphi...? VC++ 2.0 (and MFC) has been rejected by some C++ diehards, because
  110. >: it wasn't OO... (I assume they fixed this in 4.0?)
  111. >Duh. Can  you read? The 
  112. >original post said that you can't compare Delphi to MSVC++ or Object Pascal 
  113. >to C++, that you have to compare C++ to Delphi. I claimed otherwise. Comparing
  114. >Delphi to VC++ ( or Borland C++ or Symantec C++) is entirely consistent with 
  115. >my position.
  116.  
  117. VC++'s MFC library doesn't make much use of inheritance at all, does it?
  118. Atleast that's what I've been told from someone residing in one of the
  119. C++ newsgroup (maybe it was a troll, but I've heard it elsewhere as well,
  120. MFC is supposedly bad OOP)?
  121.  
  122. Anyway we gotta straighten out the mess at the top of this message before
  123. it's any point to venture deeper into this discussion. 
  124.  
  125. Take care.
  126.  
  127. -- 
  128. =\
  129.  *=- R.Moberg, CD-Player Pro info @ http://www.sn.no/~mobergru/
  130. =/
  131.